Thema: Continuous ‚Everything‘

Leuchtturm auf der grünen Wiese - Wie ein CI-Server Struktur schafft

Entwicklung auf der 'grünen Wiese' wird oft als einfacher angesehen, als die Entwicklung in einem Rahmen, der von bestehenden Systemen definiert wird. Was aber, wenn die Wiese schlicht zu groß ist und so wenig verlässliche Rahmenbedingungen existieren, dass man sich zu verlaufen droht. Dann braucht es mitunter Orientierungshilfen, welche quasi als Kompass dienen können. Ein Continuous Integration System kann - ohne Selbstzweck zu werden - eine solche Orientierunshilfe bieten.

Im Vortrag wird - wie nachstehend dargestellt - gezeigt, wie aus die Einführung und Konsolidierung einer Continuous Integration geholfen hat, aus einer mit vielen Unsicherheiten belasteten Ausgangslage zielgerichtet, konsequent und vor allem nachhaltig zu einer effizienten Softwareentwicklung zu gelangen.

Im vorliegenden Projekt sollte eine komplette Neuentwicklung einer Steuergeräteplattform erfolgen - ohne Rückwärtskompatibilität, keine Übernahme von Bestandskomponenten in SW oder HW. Die Anforderungen an die Plattform-Software waren wenig spezifisch. Als Hardwareplattform war ein Embedded Linux-Board vorgesehen.

Umstieg vom Imperativen Programmierparadigma auf OOP, neue Entwicklungsumgebung, neue Codeverwaltung, neue ALM Toolchain, ein neues, international verteiltes Team und die Einführung agiler Methoden trugen ihr Übriges zur allgemeinen Verunsicherung der bisherigen Software-Entwickler bei.
Ist es realistisch aus dieser Situation qualitativ hochwertige Software in kurzen
Entwicklungszyklen zu erwarten?

In diesem Umfeld tat sich die Umsetzung eines CI Systems als wertvolle, quasi strukturstiftende Maßnahme hervor. Obwohl bisher nicht eingesetzt, waren Continuous Build und Continuous Integration allen Beteiligten sofort eingängig und wurden gut angenommen.

Um die Integration möglichst einfach zu gestalten, wurde die Software in Komponenten unterteilt, welche sich weitgehend an der Hardwarestruktur ausrichteten. Es folgten zunächst Kommunikationsinfrastrukturkomponenten, später dann Funktionskomponenten sobald diese konzeptioniert und entworfen waren. Somit hatte die CI direkte Auswirkungen auf die Architektur. Und mit der Kompilierung der Software aus dem Code der Einzelkomponenten auf einem Referenzsystem war das erste - zugegebnermaßen noch recht simple - 'Quality- Gate' geschaffen.

Neben der Weiterentwicklung der Architektur und der Softwarefunktionalität rückte die Softwarequalität in den Blickpunkt. Zu ihrer Verbesserung wurden mehrere statische Codeanalysewerkzeuge eingebunden. Unit -Tests - bislang in der Entwicklung nicht eingesetzt - wurden für die Softwarekomponenten umgesetzt. Zunächst wurden sie im Rahmen der CI auf dem Build-Server ausgeführt. Anschließend wurde automatisches Deployment und Ausführung der Unit-Tests auf das Target umgesetzt. Die Einbindung in die CI inklusive Aufbereitung und Anzeige der Ergebnisse war dabei von Anfang an als Ziel definiert und diente zum einen als weiteres Qualifizierungsmerkmal der Software und zum anderen als Blaupause für die Entwicklung und Einbindung echter Integrations -, Performanzund Systemtests mit bzw. auf der Zielhardware.

Insbesondere die Entwicklung und der Aufbau der Umgebung dieser Tests auf der Hardware  sowie natürlich deren Durchführung lieferten wichtige Erkenntnisse und Kennzahlen über die Fähigkeiten und Grenzen des Systems. Durch die CI waren diese zudem reproduzierbar und wurden kontinuierlich erhoben und waren somit stets aktuell - und Veränderungen konnten schnell und einfach mit der jeweiligen Ursache assoziiert werden.

Somit wurde Continuous Build, Continuous Integration und Continuous Deployment entwickelt und jeder Schritt hatte vornehmlich positive Auswirkungen auf die Softwareentwicklung. Es half den Entwicklern schneller mit den neuen Techniken, Werkzeugen und Methoden vertraut zu werden und die Entwicklung insgesamt zu professionalisieren. Hinsichtlich der bis zum Ende emergenten Anforderungen steigerte es die Reaktionsfähigkeit und -geschwindigkeit im Vergleich zur Vorgängerplattform deutlich. Bislang hat man sich nicht auf den Schritt Continuous Delivery eingelassen, also die vollständig automatisierte Auslieferung der Software an Fertigung und Bereitstellung für im Feld befindliche Geräte. Eine mehrmonatige Feldtestphase ist hier vorgeschaltet.

Zusammenfassend lässt sich sagen, dass die Einführung und konsequente Weiterentwicklung der CI sich als wichtige Leitschnur bewährt und nachhaltig dazu beigetragen hat, die Softwareentwicklung zu professionalisieren.

Hendrik Spies

Hendrik Spies ist Projektleiter und technischer Consultant bei der comlet Verteilte Systeme GmbH in Zweibrücken.

Er hat Informatik an der TU Kaiserslautern studiert. Seit 2005 ist er bei der comlet und hat in dieser Zeit in zahlreichen embedded Proekten Projekten in den Bereichen Automotive, Commercial Vehicle und Automation Erfahrung sammeln und einbringen können. Im Rahmen dieser Projekte ist er seit einigen Jahren insbesondere mit dem Bereich Konfiguration Management befasst und betreut Kunden bei der Konzeption und Umsetzung von Continuous Integration, Testing und Deploymentlösungen.

Hendrik Spies

Hendrik Spies ist Projektleiter und technischer Consultant bei der comlet Verteilte Systeme GmbH in Zweibrücken.

Er hat Informatik an der TU Kaiserslautern studiert. Seit 2005 ist er bei der comlet und hat in dieser Zeit in zahlreichen embedded Proekten Projekten in den Bereichen Automotive, Commercial Vehicle und Automation Erfahrung sammeln und einbringen können. Im Rahmen dieser Projekte ist er seit einigen Jahren insbesondere mit dem Bereich Konfiguration Management befasst und betreut Kunden bei der Konzeption und Umsetzung von Continuous Integration, Testing und Deploymentlösungen.